2026-09-22 · class-notes, tryhackme, networking, tcp, udp, ports
Full class notes for TryHackMe Pre Security (2026 path) module 5, Packets & Frames: packets vs frames, the TCP/IP model, TCP headers and the three-way handshake, UDP and ports.
Class notes · TryHackMe Pre Security (2026 path) · Module 5, room 4: Packets & Frames
Quick reference: the short version of this room is the Packets and Frames cheat sheet, the fourth sheet in Module 5, after the OSI Model room. The A+ lesson on common ports covers the port list in more depth.
By the end of these notes you should be able to:
Packets and frames are both small pieces of a larger message, but they belong to different layers of the OSI model.
The room's analogy is the post. The frame is the envelope, used to carry the contents to the next place; the packet is the letter inside. When the recipient opens the envelope, the letter tells them where it should go next.
+---------------------------------------------------------------+
| FRAME (layer 2) - the envelope: source and destination MAC |
| +----------------------------------------------------------+ |
| | PACKET (layer 3) - the letter: source and destination IP | |
| | +-----------------------------------------------------+ | |
| | | SEGMENT (layer 4) - ports, sequence numbers, flags | | |
| | | +------------------------------------------------+ | | |
| | | | DATA - the bytes the application actually sent | | | |
| | | +------------------------------------------------+ | | |
| | +-----------------------------------------------------+ | |
| +----------------------------------------------------------+ |
| frame trailer: checksum for the frame |
+---------------------------------------------------------------+
The router opens the envelope (frame) and writes a new one for the
next hop; the letter (packet) inside travels unchanged.
Adding those wrappers is encapsulation, which the OSI Model room covered. A useful rule of thumb: when you are talking about IP addresses, you are talking about packets; strip the encapsulating information away and you are talking about the frame.
Splitting a message into many small pieces is more efficient than sending it in one lump. Small pieces share the network fairly, so one large transfer is less likely to block everything else, and a lost piece costs only that piece.
When you load an image from a website, it doesn't arrive as a single object. It arrives as a series of packets that your computer reassembles into the picture.
Packets have different structures depending on the protocol in use. Networking runs on standards precisely because, with billions of devices connected, nothing would work if every device invented its own format.
Taking the Internet Protocol as the example, a packet carries a set of headers alongside the data:
| Header | What it does |
|---|---|
| Time to Live (TTL) | Limits how far the packet may travel, so undeliverable packets don't circulate forever |
| Checksum | Lets the receiver detect whether the header has been corrupted in transit |
| Source address | The IP address it came from, so replies know where to go |
| Destination address | The IP address it is going to, so each router knows where to send it next |
Correction: the name "time to live" suggests a timer, and the room describes it as an expiry timer. In practice TTL is a hop count: every router that forwards the packet reduces it by one, and when it reaches zero the packet is dropped and an error message goes back to the sender. IPv6 renamed the field "hop limit" for exactly this reason.
Note (beyond this lesson): the IPv4 header checksum covers the header only, not the data, and IPv6 dropped the header checksum altogether, leaving the job to the layers above.
The TCP/IP model describes the protocols the internet actually runs on, and it is essentially a condensed version of the OSI model, with four layers instead of seven:
| TCP/IP layer | OSI layers it covers | Examples |
|---|---|---|
| Application | 7, 6, 5 | HTTP, DNS, SMTP |
| Transport | 4 | TCP, UDP |
| Internet | 3 | IP, ICMP |
| Network interface | 2, 1 | Ethernet, Wi-Fi, cabling |
As data passes down these layers, each one adds its information, exactly as in the OSI model: encapsulation on the way down, decapsulation on the way back up.
Correction: the room introduces this section with "TCP is another one of these rules" and then describes the four-layer model. They are two different things. TCP is a single transport protocol. The TCP/IP model is the four-layer model named after its two best-known protocols, TCP and IP, and it includes UDP, ICMP and everything else as well.
TCP is connection-based: before any data moves, the client and the server establish a connection through the three-way handshake (section 5). Because both ends agree on the connection and acknowledge what they receive, TCP can guarantee that data arrives, and arrives in order, or tell the sender that it could not.
| Advantages of TCP | Disadvantages of TCP |
|---|---|
| Guarantees the integrity and order of the data | Needs a working connection between the two devices throughout |
| Paces the sender so the receiver isn't flooded, or fed data out of order | Keeps state on both devices for as long as the connection lasts |
| Does extra work (acknowledging, retransmitting) for reliability | Slower than UDP, because of all that extra work |
Correction: the room says that if one small chunk is not received, "the entire chunk of data cannot be used and must be re-sent". TCP re-sends only the missing segment, not the whole transfer. It also describes the connection as "reserved on the other device": both ends keep track of the connection, but nothing on the network in between is reserved for it.
A TCP segment carries these fields, among others:
| Header | What it does |
|---|---|
| Source port | The port the sender opened for this connection, chosen from the free ports |
| Destination port | The port the service is listening on at the other end, such as 80 for a web server. Never random |
| Sequence number | Numbers the bytes in the stream, starting from a random initial value |
| Acknowledgement number | Tells the other end which byte is expected next, confirming everything before it |
| Checksum | A calculation over the segment, so the receiver can detect corruption |
| Flags | Control bits such as SYN, ACK, FIN and RST that say how to handle this segment |
| Data | The bytes being carried, such as part of a file |
Correction: the room lists "Source IP" and "Destination IP" as TCP headers. IP addresses live in the IP header, one layer down, not in the TCP header. TCP deals in ports; IP deals in addresses. The same applies to the UDP table later in the room, which lists TTL and the source and destination addresses as UDP headers: those are all IP header fields.
Correction: the room says the acknowledgement number is "the sequence number + 1". That is only true for the handshake, where SYN and FIN each count as one. During data transfer, sequence numbers advance by the number of bytes sent, and the acknowledgement number is the next byte expected: send 500 bytes starting at 1 and the other end acknowledges 501.
| Flag | Meaning |
|---|---|
| SYN | Synchronise: start a connection and share an initial sequence number |
| SYN/ACK | The server's synchronise, plus an acknowledgement of the client's |
| ACK | Acknowledges what has been received; set on almost every segment after the handshake |
| FIN | Finish: close this side of the connection cleanly |
| RST | Reset: abort the connection immediately, because something is wrong |
Correction: the room's table lists "DATA" as one of these messages. There is no DATA flag. Once the handshake is done, data simply travels in ordinary segments, which normally carry the ACK flag. The real TCP flags also include PSH and URG.
Each side picks a random initial sequence number (ISN) and tells the other about it during the handshake, so both ends agree on how the bytes are numbered and can reassemble them in order:
Client Server
| |
| 1. SYN seq = 0 (my ISN) |
|---------------------------------------------------->|
| 2. SYN/ACK seq = 5000 (my ISN), ack = 1 |
|<----------------------------------------------------|
| 3. ACK seq = 1, ack = 5001 |
|---------------------------------------------------->|
| |
| ===== connection open: data segments both ways =====
| |
| 4. FIN I have finished sending |
|---------------------------------------------------->|
| 5. ACK |
|<----------------------------------------------------|
| 6. FIN so have I |
|<----------------------------------------------------|
| 7. ACK |
|---------------------------------------------------->|
RST instead of FIN means the connection was aborted, not closed.
Using the numbers in the diagram:
Note (beyond this lesson): ISNs are random for a reason. If an attacker could guess the sequence numbers, they could inject data into, or forcibly reset, someone else's connection without seeing it. Predictable ISNs were a real weakness in older systems.
TCP closes a connection once each side has finished and everything has been acknowledged. Because a connection uses resources on both devices, it is good practice to close it as soon as the exchange is done.
The device that finishes first sends a FIN, which the other end acknowledges. When the other end has also finished, it sends its own FIN, and that is acknowledged too. Four messages in all: FIN, ACK, FIN, ACK.
A RST is the other way a connection can end. It is not a polite close but an abrupt stop, sent when something is wrong: no service listening on that port, a crashed application, or a device that refuses the connection.
In the real world: this is why "connection refused" and "connection timed out" mean different things. Refused means a RST came back, so the host is reachable but nothing is listening. Timed out means nothing came back at all, which usually means a firewall dropped the traffic.
UDP (User Datagram Protocol) is stateless: no connection, no handshake, no synchronisation. Data is sent whether or not the other end is ready, and nothing confirms it arrived.
That suits anything where losing a little data matters less than waiting: video streaming, voice chat and similar traffic, and small exchanges where asking again is cheaper than setting up a connection.
| Advantages of UDP | Disadvantages of UDP |
|---|---|
| Much faster, with far less overhead | No guarantee anything arrives |
| Leaves the application to decide how fast to send, which is flexible | The application must handle loss itself |
| Holds no continuous connection on either device | An unstable connection gives a poor user experience |
Correction: the room's UDP table has the flexibility point in the disadvantages column. Leaving pacing to the application is one of UDP's advantages, which is how the transcript describes it in the surrounding text.
A UDP header is much simpler than a TCP one: source port, destination port, length, checksum, and then the data. There are no sequence numbers, acknowledgements or flags, because there is nothing to keep track of.
A port is a numbered point where data enters or leaves a device, and the room's analogy is a harbour: a ship can only dock where the berth fits it. Once a connection is established, everything sent or received travels through these ports. Port numbers run from 0 to 65535.
With that many ports, standards keep things orderly. Because web traffic is agreed to use port 80, anyone writing a browser knows where to send it, and any web server knows where to listen. The browser's looks and features are up to its designers; the port is not.
Correction: the room says "any port within 0 and 1024 is known as a common port". The usual name and boundary are different: 0 to 1023 are the well-known ports, assigned to standard services and, on Unix-like systems, usable only by administrative accounts.
| Range | Name | Used for |
|---|---|---|
| 0 to 1023 | Well-known | Standard services: HTTP, SSH, DNS and the rest |
| 1024 to 49151 | Registered | Applications registered with IANA, such as databases |
| 49152 to 65535 | Dynamic or ephemeral | Temporary source ports for outgoing connections |
Note (beyond this lesson): the "random" source port a client picks comes from the ephemeral range. Different systems use slightly different ranges: Linux commonly uses 32768 to 60999.
| Protocol | Port | What it does |
|---|---|---|
| FTP | 21 | File transfer between a client and a central server |
| SSH | 22 | Secure, text-based remote login and management |
| HTTP | 80 | The web: text, images and video of web pages |
| HTTPS | 443 | The same, encrypted |
| SMB | 445 | File sharing, and shared devices such as printers |
| RDP | 3389 | Remote login to a graphical desktop |
The full list of assignments is kept in IANA's Service Name and Transport Protocol Port Number Registry.
These are conventions, not rules enforced by the network. You can run a web server on port 8080 instead of 80. Because software assumes the standard, you then have to name the port explicitly, after a colon: http://example.com:8080.
A colleague sends you http://192.168.1.50:8080/admin and says "the dashboard is up".
http:// means plain HTTP, which is unencrypted, so anything sent, including a login, is readable on the path.192.168.1.50 is a private address, so this is reachable only from inside the network.:8080 is the non-standard port. Without it, the browser would try port 80 and fail.host:port.| Term | Meaning |
|---|---|
| ACK | The TCP flag acknowledging data received |
| Checksum | A calculated value used to detect corruption in transit |
| Ephemeral port | A temporary high-numbered port a client uses as its source |
| Encapsulation | Wrapping data in each layer's header on the way down the stack |
| FIN | The TCP flag that closes one side of a connection cleanly |
| Frame | A layer 2 unit of data, addressed by MAC address |
| Initial sequence number (ISN) | The random starting number each side picks for its byte numbering |
| Packet | A layer 3 unit of data, addressed by IP address |
| Port | A number from 0 to 65535 identifying a service or a connection endpoint |
| RST | The TCP flag that aborts a connection immediately |
| Sequence number | The number identifying where a segment's bytes sit in the stream |
| Stateless | Keeping no record of a connection, as UDP does |
| SYN | The TCP flag that starts a connection and shares a sequence number |
| TCP/IP model | The four-layer model: application, transport, internet, network interface |
| Three-way handshake | SYN, SYN/ACK, ACK: how a TCP connection is established |
| Time to live (TTL) | A hop count that stops undeliverable packets circulating forever |
| Well-known ports | Ports 0 to 1023, assigned to standard services |
http://example.com:8080. Otherwise the browser tries port 80.